Integrated circuits (ICs) have become the backbone of modern consumer electronics. The increased demand for functionality of consumer electronics has forced the complexity of IC's to skyrocket. In a number of applications, ICs must be highly functional, low cost and have low power consumption. These demands create increased complexity on the design, verification, and manufacture of ICs.
A typical IC design may involve the creation of electronic components, such as transistors and resistors, and the interconnections of these components onto a substrate, such as silicon. The simulation, verification, and sometimes layout of these components usually is accomplished in sub-blocks, or modules. Each block may be simulated and verified individually. Multiple design teams typically work on the individual blocks. During the design process functional verification is critical.
Functional verification involves the verification that the design conforms to the specification. Functional verification may involve the validation that a design meets the desired functionality. Part of the process of verification includes the creation of Register Transfer Level (RTL) digital designs that describe in detail the functionality of the device or block at every cycle of the clock. Creation and verification of RTL designs may be one of the more difficult portions of the design process. In many instances, this verification is a very difficult and time intensive task. Simulation tools are typically used to assist in verification. In most designs, simulation-based functional verification is performed on multiple machines in parallel. During the verification process “coverage” data is produced that may indicate which portions of the functionality and/or code have been tested.
Until recently, using coverage in the verification cycle of digital designs was done using a very simple flow and was restricted mainly to using code coverage. In the simplest flow, a design under verification (DUV) is simulated using multiple testbenches and a coverage database is generated for the DUV for each simulation run. Once all the simulations have been run, the coverage databases obtained from each run are merged together to get a comprehensive view of the coverage obtained from the entire verification.
If the design under verification (DUV) is identical across all the simulation runs, the merge is straightforward since the design hierarchy and the set of coverage points are identical. In practical usage, this is not the case. Multiple design teams may work on individual blocks of a chip. In order to get a complete view, the coverage results from simulations of the individual blocks may need to be stitched together to get the chip-level view. Different configurations of a chip may be run in different simulations. As part of user methodology, different simulation runs of the same design may have different modules at different levels of abstraction. For example, one level of abstraction may contain modules written in a higher level language, such as systemC, while another may be written in a low level language such as a Hardware Description Language (HDL). As multiple teams work on various parts of a design and the design evolves over time, both the design hierarchy (affecting code coverage) and the functional coverage points (affecting functional coverage) may undergo changes.
If the verification goal is not met then additional tests may be created to cover the uncovered area of the design. When the verification goal is met, test ranking may be performed to determine the minimum set of tests, which may subsequently be used as the regression test-suite. In this manner, test ranking may be utilized to remove redundant tests from the test-suite.